@BeryJu please review

@BeryJu i do not know where this CI error cames from:

Error: INSTALLATION FAILED: serviceaccounts "authentik-q63g50s5tb" already exists

solved

#156

thanks @benedikt-bartscher i will add the sidecar to all component

done - lets review again

I can vouch that this sidecar works as expected. Nice work @genofire. New configmaps with label goauthentik_blueprint: "1" and:

data:
  blueprint_test.yaml: |
    <blueprint yaml>

(or any other yaml filename) result in blueprint in Authentik. Deletion of configmap removes from Authentik. Be great to get this merged. I've not tried the operator, but this seems a lower-effort way to deliver gitops blueprints. CRD & controller will have to be kept up-to-date with the blueprint spec. This is lower maintenance.

Only downside is blueprints containing secrets referred to using env var tag eg !Env <app>_client_secret don't get updated. When these env vars are mounted using helm chart value: worker.envFrom[0].secretRef.name: <my_k8_secret_containing_env_vars_to_mount_in_authentik_worker> and this secret is updated (eg an oauth client_secret is changed), the env vars mounted don't change until worker restart, nor does the blueprint get reloaded and update the Authentik construct defined in the blueprint. I guess the solution would be for this sidecar to watch for changes to the worker.envFrom[0].secretRef.name secret, and reload blueprints when it does. Happy to break this out into a separate issue, as sidecar needs to be implemented first!

you could store the blueprint in a kubernetes Secret eigther (instatt of ConfigMap).

So your secrets are stored secure.

For your problem, maybe there could this operator works reloader

Good suggestions. Long story, but need to stick with configMaps and !Env <my_env_var>. Reloader now rolling-restarts my worker pods when the secret that defines env vars changes, and I'm patching the worker deployment so it runs ak apply_blueprint to apply sidecar blueprints at startup (which have access to new env vars). When this PR is merged, I'll create a new PR, as I think applying blueprints at startup will be useful as an option beyond this use-case to prevent drift. Maybe worker.applySidecarBlueprintsAtStartup: true\false, with default of false?

Nearly gitops Authentik :-) Just need resources created by deleted blueprints to be cleaned up.